One technique for analyzing or debugging a program employs a call graph that indicates function calls made during an execution of a computer program. A call graph may include temporal information, indicating a sequence of function calls. One way of generating a call graph is to insert instructions within the user program, the execution of the instructions causing certain events to occur. During execution of the computer program, these events may be written to a log file. After execution of the computer program, an analysis program may examine the log file and generate a call graph, based on the sequence of events. This technique is referred to as a call trace, and the events are referred to as call trace events. A developer may use the call graph generated by a call trace to analyze the computer program in order to find problems, such as bugs or inefficiencies. In some environments, portions of a computer program, or functions invoked by a computer program, may not be available to insert event instructions. For example, system functions or library functions may be invoked, either of which may not be available for inserting event instructions.
Another debugging technique involves taking a snapshot of the program's call stack. During execution of the program, a developer may break execution of the program at a desired point, and examine the contents of the call stack. The call stack indicates a sequence of frames. The frames correspond to functions that are currently invoked, with the top frame of the stack indicating the current function, the next frame down indicating a parent function, and so forth. Some debugging systems may periodically take snapshots of the call stack and write them to a log file, for a later analysis by a developer. This technique is referred to as a sample trace. Sample traces provide accurate information, though it may be incomplete due to the fact that they are simply snapshots of an executing program.